COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002		eXTRA stuff about the recent IJCAI paper.
C00006 00003		Outtakes
C00014 ENDMK
C⊗;
	eXTRA stuff about the recent IJCAI paper.
	Communications
∂Mailed to CSD.LENAT@SCORE 23:34 18-Feb
IJCAI Proposal
Doug -
	I thought a possible IJCAI topic would be an Overview of EURISKO.
The paper would what this system-to-be will be, meandering about to
cover a few closely-related topics.
First, a definition: what is EURISKO, and what will it do.
Second, the preconditions for such a systems.
[Here we could plug your Theory of Heuristics paper; and
then spend a good while indicating why a rll is necessary.
Of course, during the motivation we'd be defining this beast as well.]
Third, a description of how we handled rules/heuristics (combining bits
from the things above).
Fourth would be a statement of current status - both in terms of
solid implementation and vague ideas.
The conclusion would list our plans for the future.

Assuming this draft was accepted, come May the future tense-d parts could be 
changed - either simply present-ed, or drastically altered to correspond to
the by-then more-nearly-implemented system.

Anyway, I've a more complete outline, together with what may be a rough
draft of the first few pages.
A week and a half from now is March 1st.  We should get together and
discuss this.
When do you plan to be in tomorrow (19-Feb)?

	Russ

∂19-Feb-81  1150	CSD.LENAT at SU-SCORE 	Re: IJCAI Proposal    

Just got back from Washington; I wil be in Friday, and we can
plan to meet around 11 to talk about your idea.  It may fly
(mayfly?)
Doug
-------

∂Mailed to DBL 23:12 24-Feb
Done, sorta
Ok - the draft is essentially done.
(or at least I completed that iteration.)
It is now 9064 words, after removing the Outline, outtakes, etc.
That's only 50% over.
I already sacrificed (ie didn't bother even starting to write) two of the
sections...

See you tomorrow.
	Russ

PS I had to contact Rick last Thursday, and tried using the magic
account number, 23088, you gave me a few years ago.
It didn't work.  Can you forward the new number, or is that priveledged
information?

∂Finally met 26-Feb, decided to flick it in.

	Questions:
Historically, what was EURISKO's real mission:
	1) To do AM stuff, in many domains
	2) To generate new and useful heuristics.
	3) To facilitate inputting new KBs (and building expert systems?)

The "Why is this important" part is now in the conclusion - should it be
in the introduction as well? If so, where?
	Outtakes

	<Why this representation language must be modifiable?>
As the introduction repeatedly claimed, EURISKO must be able to modify
not only the concepts on which it is working, but its own structure 
as well. 
That is, EURISKO must be able to alter any of its parts as necessary.
One way of acheiving this goal (the one we chose) is to leave the
EURISKO's parts in a declarative form...
This capability means the components of its underlying systems
must be both explicit, and mallible.

The EURISKO system (Greek for `I discover') is built to carry out the 
type of exploration task which AM pioneered, in arbitrary fields.
As a second system, we hope to avoid those pitfalls which hampered AM,
and which made it impossible to extend.
Its basic operation will be to select a field, eg Mathematics, for investigation,
meander about that domain, working on those topics (such as Number Theory)
whose current interest rating suggest this subdomain has potential.
When no such topics remains, EURISKO will summarize its experience,
and move on to a new field - say Molecular Genetics.

XI. Example Applications
	Field of Molecular genetics
	Why desirable 
	  > structure of the field [natural hierarchies, <like Music>]
	  > "ripeness" of computerization [success of MOLGEN]
	  > Not much "common sense", "real world knowledge" {really} required
		[Unlike NL, analogy-finding in general]
	Bad side - of peripheral field's

This explicitness permits EURISKO to 
apply its knowledge of programming to reason about, and improve
its own processes and data structure,
using the same procedures it would use to update any other program.

Enhanced facts about Causal model - physics, as it was used advantageously here.
So new facts added to EURISKO's bank of data, as well as to its procedures
(although added declaratively, thanks to representation).
Might also see what else used same assumption EURISKO had, and flag this as
candidates for change.

The user first outlines his conception of the structure of his domain --
here VLSI design.  In this description he will include the major categories
of data, and how they interrelate -- e.g. "diffusion layers are impressed on
silicon wafers", or "components can be described hierarchically".

Throughout this process, tasks may be added to the running agenda which
will try to DeriveUsefulHeuristics.  Anything they derive is thrown in the
soup of rules, permitting it to be used wherever necessary (as well as in
the actual task which motivated its creation).
Note it is in a format which permits it to either be "executed", or
the subject of an examination (ie reasoned about, to create yet other
rules, or query its efficiency, relation to other rules, ...)

	? What is this?
EURISKO will be able to expand its vocabulary -- its collections of
heuristics, etc - with the same ease 
(in fact, possibly using the exact same mechanism)
it uses to add in new domain concepts, and fleshing
such new ideas out.
It will, in fact, be able to introspect on its own operations, with an
option of reconfiguring itself (in major or minor ways) if its
`usefulness' criteria indicates a change is desirable.
Through its use of self-reflection, EURISKO will be able to use the
same basic operations to perform such meta-level tasks that it used to
`redesign' other domain level concepts.

The preceding scenario provided a sketchy "behaviouristic" model EURISKO,
as  a sequence of stimulus/response pairs.
We will now present a sketch of how it works, internally.
Following a description of its exploration facility, we will elaborate
general characteristics of its processes devoted to speedy KB input.

In addition, we will argue below that the actual
mechanism used for deductions, as well, should be left in user-control.

Requirements for the underlying language:
(1) Generality - it must be able easily represent - NL, Games, ...
	as well as things not thought of, yet (spills [H-R,W&L])
(2) Parts visible, so system can reason about it.
	Parts of the language itself have to be open to inspection -
	including relations, inference rules, ...
(3) Should be allow to modify these parts (possible 'cause you can see them)
	First user, then EURISKO, should be able to reorganize inferences,
	onto ones more efficient..